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Abstract 

VLSI  CAD  systems  are  typically  large  and  undergo  frequent  changes. 
A  frustrating  aspect  of  these  changes  is  that  so  little  of  the  old  avail¬ 
able  programs  can  be  reused.  The  reason  is  that  it  takes  too  much 
time  and  effort  to  find  the  reusable  pieces  and  recast  them  for  the  new 
use. 

We  believe  that  such  systems  should  be  designed  for  reusability  by 
anticipating  change.  Our  thesis  is  that  this  goal  can  be  achieved  by 
designing  the  software  as  layers  of  problem  oriented  languages,  which 
are  implemented  by  suitably  extending  a/base'",  language.  A  language 
layer  rarely  needs  to  be  adapted  to  changes,  only  the  application  (i.e. 
algorithm)  needs  to  be  changed. 

We  illustrate  this  methodology  with  respect  to  VLSI  CAD  pro¬ 
grams  and  a  particular  language  layer:  a  language  for  handling  net¬ 
works.  A  concept  shared  by  many  CAD  programs  is  that  of  networks 
consisting  of  components  and  their  interconnects.  We  capture  this 
common  part  by  providing  a  langae^e  ht  handling  network  problems. 
Such  a  language  consists  of  our^  “base”^  language  (EC  or  Lisp)  plus 
data  types,  operations  and  control  structures  that  are  relevant  to  net¬ 
work  problems.  The  network  language  is  but  one  of  several  languages 
used;  other  languages  we  use  deal  with  sets,  two  dimensional  layout 
structures,  waveforms,  etc.  The  dbcussion  of  the  network  language 
illustrates  this  technique. 

We  present  two  different  implementations  of  the  above  philosophy. 
The  first  uses  UNIX  and  Enhanced  C,  a  set  oriented  language  support¬ 
ing  data  abstractions  based  on  C.  The  second  approach  uses  Common 
Lisp  on  a  Lisp  machine.  In  each  case,  we  describe  the  basic  technique 
and  its  applications.  We  conclude  by  comparing  the  two  approaches.  - 
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Abstract 

VLSI  CAD  systems  are  typically  large  and  undergo  frequent  changes. 
A  frustrating  aspect  of  these  changes  is  that  so  little  of  the  old  avail¬ 
able  programs  can  be  reused.  The  reason  is  that  it  takes  too  much 
time  and  effort  to  find  the  reusable  pieces  and  recast  them  for  the  new 
use. 

We  believe  that  such  systems  should  be  designed  for  reusability  by 
anticipating  change.  Our  thesis  is  that  this  goal  can  be  achieved  by 
designing  the  software  as  layers  of  problem  oriented  languages,  which 
are  implemented  by  suitably  extending  a  “base”  language.  A  language 
layer  rarely  needs  to  be  adapted  to  changes,  only  the  application  (i.e. 
algorithm)  needs  to  be  changed. 

We  illustrate  this  methodology  with  respect  to  VLSI  CAD  pro¬ 
grams  and  a  particular  language  layer:  a  language  for  handling  net¬ 
works.  A  concept  shared  by  many  CAD  programs  is  that  of  networks 
consisting  of  components  and  their  interconnects.  We  capture  this 
common  part  by  providing  a  language  for  handling  network  problems. 
Such  a  language  consists  of  our  “base”  language  (EC  or  Lisp)  plus 
data  types,  operations  and  control  structures  that  are  relevant  to  net¬ 
work  problems.  The  network  language  is  but  one  of  several  languages 
used;  other  languages  we  use  deal  with  sets,  two  dimensional  layout 
structures,  waveforms,  etc.  The  discussion  of  the  network  language 
illustrates  this  technique. 

We  present  two  different  implementations  of  the  above  philosophy. 
The  first  uses  UNIX  and  Enhanced  C,  a  set  oriented  language  support¬ 
ing  data  abstractions  based  on  C.  The  second  approach  uses  Common 
Lisp  on  a  Lisp  machine.  In  each  case,  we  describe  the  basic  technique, 
and  its  applications.  We  conclude  by  comparing  the  two  approaches. 
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1,  Introduction 

CAD  software  systems  are  a  collection  of  programs  where  the  results  of  one  pro¬ 
gram  are  the  inputs  of  another.  These  programs  are  large,  complex  and  usually  CPU 
limited — often  written  independently  and  put  together  as  the  need  arises.  The  pro¬ 
grams  are  frequently  changed.  These  changes  may  be  due  to  changes  in  VLSI  technol¬ 
ogy,  but  often  they  are  also  a  result  of  the  continuing  evolution  of  the  CAD  algorithms 
themselves.  A  better  understanding  of  an  algorithm  often  leads  to  performance  im- 
l^rovcunents  or  better  use  of  the  algorithm.  These  improvements  may  be  conceptually 
simple  while  their  effect  is  pervasive,  such  as  changing  a  datatype  from  a  list  to  a  2-D 
tree.  As  a  result,  a  satisfying  CAD  system  is  a  moving  target. 

A  frustrating  aspect  of  writing  new  systems  is  that  so  little  of  the  old  available 
programs  can  be  reused.  The  reason  is  that  it  takes  too  much  time  and  effort  to  find 
the  reusable  pieces  and  recast  them  for  the  new  use.  To  reuse  someone  else’s  software 
requires  understanding  the  details  of  his  or  her  program.  Sometimes  understanding 
these  unstructured  details  takes  more  effort  than  rewriting  the  program  again. 

We  believe  that  such  systems  should  be  design  for  reusability  by  anticipating 
change.  Our  thesis  is  that  this  goal  can  be  achieved  by  designing  the  software  by 
layers  of  problem  oriented  languages.  These  languages  are  implemented  by  suitably 
extending  a  “base”  language.^ 

In  this  paper  we  illustrate  the  above  methodology  with  respect  to  VLSI  CAD 
programs  and  a  particular  language  layer:  a  language  for  handling  networks.  Networks 
made  of  components  and  their  interconnections  is  a  concept  shared  by  many  CAD 
])i  ogiauis.  We  capture  that  ccjmnion  part  by  providing  a  language  for  handling  network 
problems.  Such  a  language  consists  of  our  “base”  language  (EC  or  LlSP)  plus  data 
types,  operations  and  control  structures  that  are  relevant  to  network  problems.  The 
network  language  is  but  one  of  several  languages  used;  other  languages  we  used  deal 
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with  sets,  two  dimensional  layout  structures,  waveforms,  etc.  The  discussion  of  the 
network  language  illustrates  this  technique. 

A  key  part  of  the  implementation  technique  is  that  the  base  language  is  extensi¬ 
ble.  We  solve  a  particular  set  of  problems  by  extending  the  base  language,  forming  a 
problem  oriented  language  for  the  particular  problem  at  hand  (for  example,  a  language 
for  manipulating  waveforms  or  the  network  language  discussed  below).  Of  particular 
importance  are  language  layers  that  capture  concepts  intrinsic  to  the  field.  Design 
based  on  such  layers  has  the  follow  advantages: 

(a)  The  programs  are  self  documenting  and  document  themselves  concisely.  The  bulk 
of  the  documentation  describes  the  problem  oriented  language  and  not  individual 
programs. 

(b)  Changes  involve  writing  a  new  algorithm  in  the  same  (problem  oriented)  language 
rather  than  writing  a  new  language.  This  automatically  ensures  that  new  programs 
use  parts  of  old  programs.  These  parts  are  the  concepts  encapsulated  in  the 
language. 

(c)  The  language  rarely  needs  to  be  adapted  to  changes,  only  the  application  (i.e. 
algorithm)  has  to  be  changed.  Occasionally,  the  language  may  also  need  to  be 
extended. 

^^  e  base  our  conviction  in  the  power  of  the  language  approach  upon  the  progress 
made  in  other  fields  by  developing  languages  to  express  problems  and  their  solutions. 
For  example,  one  of  Newton’s  major  contribution  to  physics  weis  the  development  of 
Calculus  which  can  be  viewed  as  a  collection  of  new  concepts  and  ways  of  putting  them 
together. 

The  changes  in  digital  design  field  over  the  last  two  decades  have  been  so  drastic 
that  one  wonders  how  the  field  maintained  its  unity.  We  claim  that  the  stability  of  the 
practitioners  language,  the  TTL  conventions,  is  the  source  of  this  unity.  In  spite  of  the 
technological  changes  the  language  adapted  remaining  relatively  constant,  maintaining 
communication  among  workers  in  the  field  and  preserving  the  field  unity. 

Consider  another  aspect  of  this  same  problem.  Most  conventional  design  method¬ 
ologies  begin  with  a  specification  of  the  system  to  be  built.  The  specification  should  be 
as  complete  and  as  accurate  as  possible.  Using  this  specification,  the  system  is  divided 
info  smaller  systems,  each  with  their  own  specification.  These  sub-systems  can  be 
attacked  independently  since  they  need  only  satisfy  their  specifications.  This  method- 
f>l<7gy  i,s  generally  known  as  structured  design  and  is  widely  acclaimed  and  accepted. 

however,  feel  that  this  methodology  is  inadequate  for  building  large  systems. 
The  key  flaw  in  structured  design  is  the  reliance  on  the  accuracy  of  the  specification.  For 
sufficiently  large  systems,  the  specification  is  always  incorrect.  At  the  beginning  of  the 
project,  the  ])roject  itself  is  not  completely  understood  and  neither  are  its  components. 
During  the  ])roject,  the  better  understanding  the  algorithms,  data  structures  and  their 
uses  leads  to  modifications  of  the  detailed  specifications.  At  the  of  the  project,  what 
was  built  may  meet  the  original  specification,  which  was  not  what  the  client  really  had 
want('(!.  The  client  had  not  specified  what  he  had  thought  he  had  specified. 
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How  cnu  wo  deal  with  incorrect  and  ever  changing  specifications?  We  can  only 
assume  that  the  evolving  specification  is  not  far  wrong.  It  describes  a  family  of  systems 
near  the  desired  one.  We  suggest  building  a  platform  on  which  this  nearby  family 
of  systems  can  be  built  quickly.  This  platform  is  the  problem  oriented  language  we 
advocate.  This  language  simplifies  the  construction  of  the  specified  system,  and  when 
the  specification  is  modified,  it  is  straightforward  to  build  a  new  version  of  the  system. 
The  platform  itself  remains  constant  in  the  face  of  changes  in  the  specification,  since  it 
depends  upon  the  problem  domain  rather  than  a  specific  problem. 

At  this  point  an  historical  note  is  in  order.  In  the  LiSP  community,  Joel  Moses 
was  the  first  to  suggest  that  layered  languages  would  be  an  effective  way  of  dealing 
with  design  in  the  face  of  change.  In  the  programming  language  community  the  related 
notions  are  “p^^o^lem  oriented  languages”  and  “extensible  languages.”  The  practice  of 
problem  oriented  languages  leads  to  layers  of  languages.  Conversely,  the  implementa¬ 
tion  of  layers  of  languages  leads  uses  language  extensibility  in  order  to  build  proljlem 
oriented  languages. 

We  start  by  presenting  the  common  denominator  for  network  problems — the  lan¬ 
guage  for  handling  networks.  We  continue  by  presenting  two  different  implementations 
of  the  above  philosophy.  The  first  uses  UNIX  and  Enhanced  C  [8],  a  set  oriented  lan¬ 
guage  supporting  data  abstractions  based  on  C.  The  second  approach  uses  Common 
Lisp  on  a  LiSP  machine  [13,  15].  In  each  case,  we  describe  the  basic  technique  and 
its  applications.  We  conclude  by  comparing  the  two  approaches.  The  two  a\ithors  got 
together  to  write  this  artich*  when  they  discovered  their  goals  and  philosophy  were 
similar,  but  their  techniqties  differ. 

The  body  of  the  paper  is  organized  as  follows.  Section  2  describes  a  general  network 
framework  for  CAD  that  both  the  EC+UNIX  and  the  LisP  approaches  share.  This 
is  th('  fundamental  abstraction  used  in  this  paper.  In  Section  3,  we  discuss  how  EC 
can  be  used  to  implement  and  take  advantage  of  the  network  abstraction.  Section  4 
briefly  summarizes  the  different  approaclw's  used  by  LiSP  for  the  same  problem.  The 
methodology  has  been  used  for  constructing  logic  simulators  [7],  VLSI  layout  system 
[17]  and  a  system  for  analyzing  linear  networks.  In  the  final  section  we  discuss  the 
practical  experience  gained  by  using  the  methodology  and  we  also  compare  the  two 
api)roaches  taken. 

2.  Basic  Network  Model  and  Its  Language 

We  speak  about  entities  that  have  endpoints.  Networks  are  formed  by  identifying 
(connecting)  endpoints  of  entities.  An  entity  has  properties  that  contain  values.  One 
>nch  pnqx'i  ty  of  an  entity  is  its  type.  The  vjtha*  of  the  type  property  determines  the 
number  and  kind  of  the  other  properties  that  the  entity  has.  In  network  problems  we 
lia\e  a  type  node  and  a  type  component.  A  node  has  a  single  endpoint  that  can  only 
b(  coniHTted  to  the  endpoints  of  components.  This  is  illustrated  in  figure  1.  Clearly, 
tliis  is  a  v<'ry  general  model  perhaps  more  general  than  required  for  networks.  We  are 
not  iiiferrsted  in  minimal  models,  instead  we  show  that  the  major  network  constructs 
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Figure  1,  An  example  of  Nodes  and  Components 


can  be  built  simply  within  this  model. 

A  hierarchical  network  is  created  by  using  a  component,  C,  with  a  property  parent 
whose  value  is  a  network  rj.  The  nodes  of  rj  are  assigned  an  endpoint  property  that  is 
either  “empty”  or  refers  to  a  suitable  endpoint  of  C. 

A  homological  copy  of  a  network  is  an  important  and  useful  concept  [10].  A 
liomological  copy  of  r;  is  a  another  network  p.  such  that  each  node  or  component  of  r/  is 
associated  with  a  node  or  component  of  p  (possibly  a  many  to  one  relation).  Clearly 
that  association  is  a  property  of  p's  elements  and  p  can  be  manipulated  at  will  as  long 
as  T]  remains  constant.  As  an  example  consider  the  schematics  that  a  designer  might 
use  to  describe  a  circuit.  The  schematics  have  more  spatial  detail  than  would  be  needed 
Iw  a  simulator  which  would  work  with  a  topological  equivalent  representation  of  the 
schematics.  This  topology  is  a  homological  copy  of  the  schematics.  This  concept  of 
homological  copies  is  similar  to  the  Sussman’s  Slices  [16]. 

.Ground  these  entities  we  construct  a  language  that  enables  us  to  handle  these 
entities.  The  language  allows  us  to  refer  to  and  change  their  properties;  perform  trans- 
fonnations  on  them  and  use  the  entities  in  more  complex  control  structures.  In  more 
t('chnical  terms,  we  define  a  language  by  defining  constructors,  selectors,  various  other 
operations,  and  control  abstractions  that  are  appropriate  to  our  network  problems.  The 
folkwing  examples  illustrate  both  the  language  and  its  use  for  writing  CAD  application 
programs. 

2.1  Displaying  a  Circuit 

Each  (’lenient  of  the  network  (both  nodes  and  components)  has  a  property,  say 
picture,  whose  v'alue  is  (refers  to)  the  code  that  displays  the  element  picture  (jn  tlu' 
xK’f’n.  In  addition,  there  is  a  coordinates  property  that  give  the  locati(rn  of  the 
ek  lueut  on  the  screen.  The  following  loop  generates  a  picture  of  the  network: 


forall  elements  e  of  network  N  do 
display -element (e) 


display  checks  if  e.  picture  is  nil;  if  .so,  it  recurses  on  e’s  subcircuit. 


display -element (element)  { 

if  (element .picture  ==  nil) 

display _network(element .network) 

else 

element . picture (element . coordinates) 

} 

Obviously,  the  same  sort  of  operations  could  be  written  in  LiSP.  Throughout  this 
paper  all  of  our  LiSP  programs  are  written  in  Common  Lisp  [15].  We  would  begin  by 
writing  a  function  that  takes  two  arguments.  The  first  is  a  network  and  the  second  is 
a  functional  argument  that  is  applied  to  each  element  of  the  first  argument.  Call  this 
function  map-over-elements. 

(defun  display-network  (network) 

(map-over-elements  network 
(function  display-element))) 

The  display-network  function  displays  a  network  by  applying  the  function  display- 
element  to  each  element  of  network.  The  form  (function  display-network)  is  re¬ 
turns  the  function  associated  with  the  identifier  display-element.  This  extra  bit 
of  complexity  is  needed  because  Common  Lisp  allows  a  value  and  a  function  to  be 
associated  with  the  same  symbol 

(defun  display-element  (element) 

(if  (null  (picture  element)) 

(display-network  (network  element)) 

(f uncall  (picture  element)  (coordinates  element)))) 

2.2  Siinulatioii 

Consider  the  following  examples  of  simulation  programs;  synchronous  and  asyn¬ 
chronous  logic  simulation,  analog  simulation,  timing  simulation  [9],  etc.  Although  quite 
different,  these  programs  have  much  in  common.  Each  can  be  generated  by  programs 
that  traverse  the  networks,  using  the  properties  of  the  network  elements.  In  each  case 
the  handling  of  the  results  is  similar;  result  waveforms  have  to  be  associated  with  the 
network  elements  so  that  the  user  can  refer  to  them  as  properties  of  the  elements. 

For  each  kind  of  simulation  we  need  different  network  element  properties  and  a 
different  “generation  function” — the  function  that  generates  the  simulator  from  the 
network  description. 


The  above  is  illustrated  by  an  example  of  a  simple  synchronous  logic  simulation. 
We  assume  that  the  behavior  of  each  component,  e,  is  a  finite  state  machine  described 

•Sn+l  —  fei^ni 

where  i'n  is  the  state  vector  at  time  n  and  /„  is  the  input  vector  at  time  n.  For  simplicity 
assume  that  s„  is  also  the  output  vector  at  time  n  and  that  inputs  to  all  components 
are  outputs  of  other  components.  /*  is  called  the  device  function. 

The  following  simple  program  generates  the  simulation  program. 

forall  elements  e  of  network  N  do  { 

gen(  state  and  nextjstate  variable  declarations  for  e)  ; 
gen("get_initial_conditions(e. state)"  )  ;  } 
gen  ("for  (t  =  to  ;  t  <=  t  max  ;  ■t++)  {") ; 
forall  elements  e  of  network  N  do  { 

gen  ("e.devicefun(e. inputs,  e. state,  e . next_state) ; "  )  ;  } 
gen  ("forall  elements  e  of  network  iV  do  { 

e. state  =  e.next_state; 
store_results(e. state) ; ); 

gen  ("}"); 

The  following  LiSP  fragment  implements  the  same  functionality  as  the  previous  EC 
one.  In  LisP  we  do  not  generate  a  program  but  we  run  directly  off  the  data  structure. 
Notice  also  that  we  do  not  generate  any  variable  declarations. 

(map-over-elements  N 
(lambda  (e) 

(setf  (state  e)  (initial-conditions  e)))) 

(loop  for  t  =  to  below  t  max 

do  (map-over-elements  N 
(lambda  (e) 

(push  (funcall  (devicefun  e)  (inputs  e)  (state  e)) 
(state-history  e))))) 

(loop  for  t  =  to  below  t  max 

do  (map-over-elements  N 
(lambda  (e) 

(setf  (state  e)  (first  (state-history  e)))))) 

The  special  forms  begining  with  lambda  arc  used  to  create  anonymous  functions. 
The  si)ecial  form  setf  is  used  to  perform  all  assignments  in  Common  Lisp.  The  state- 
history  slot  of  each  element  is  a  list  of  the  states  through  which  the  element  has  passed. 
The  first  component  of  state-history  corresponds  to  the  next-state  variable  used 
in  the  EC  program. 


these  two  approarhes  have  in  conitnon  is  that  each  element  must  contain  its 
ilevice  function,  information  alio.it  its  state,  initial  conditions  and  connectivity.  The 
following  remarks  relate  to  these  two  vi-rsions  of  the  simulation  example. 

(a)  The  example  is  indeed  straight  forward.  Some  of  the  simplicity  is  a  result  of  this 
])articular  simulation  method.  Under  the  conditions  stated,  the  order  of  the  calls 
to  the  device  function  in  the  time  loop  can  be  arbitrary. 

However,  we  believe  that  given  the  appropriate  network  language  the  "core’’  of 
the  any  network  application  is  quite  simple.  That  is,  it  is  simple  compared  with 
the  layers  of  software  around  it  the  I/O  package,  the  handling  of  libraries,  the 
manipulation  of  results,  etc.  In  our  case,  these  facilities  are  provided  as  part  of 
the  software  environment.  They  an*  provided  as  standard  interfaces  (driven  by 
suVi-languages)  to  be  used  by  any  network  apiilication.  The  internal  complexities 
of  these  facilities  arc  th('  user. 

( b)  The  EC  version  generates  a  program.  This  jnogram  is  compiled  and  run  to  produce 
results.  The  L  ISP  version  is  a  jnograni  that  runs  to  produce  results.  The  techniques 
and  differences  between  the  two  approaches  are  elaborated  in  the  secpiel. 

(c)  With  each  application,  different  information  is  associated  with  the  network  ele¬ 
ments. 

(d)  In  all  cases  the  computed  results  have  to  be  associated  with  the  original  network 
model  to  enable  communications  with  the  user. 

3.  Implementation  using  Enhanced  C  plus  UNIX 

The  de.sign  f)f  Enlianced  C  (EC)  and  its  philo.sophy  are  described  in  [8].  EC  is  a 
s('t-oriented.  extensible.  C-like  language.  Extensibility  in  EC  involves  the  use  of  data 
aljstractions  to  define  new  types.  EC's  data  abstractions,  called  clusters,  are  macro-like 
devices  that  perform  substitutions  on  the  typed  syntax  tree.  EC’s  set  orientation  and 
data  abstractions  are  important  to  our  discussion.  We  shall  elaborate  on  these  topics 
l)efore  describing  the  organization  of  the  CAD  system. 

A  set-oriented  language  is  a  language  containing  high  level  data  aggregates.  In  EC 
these  are  sets,  sequences,  tuples  and  ‘‘oiu'of's.  ’  The  semantics  of  sets  and  sequences 
are  as  in  mathematics.  As  programming  entiti('s  they  may  l)e  thought  of  as  the  gen¬ 
eralization  of  the  array.  Tuples  and  oneofs  an'  the  generalization  of  C's  "structure" 
aiifl  ''union  respectively.  \\  ith  these  data  aggn’gates  come  expressions  and  control 
sraU'iiients  that  resemble  s('t  usage  in  matlu'inatics;  for  ('xample: 

Let  5  be  a  set  of  a  given  type,  and  .r  an  object  the  same  type. 

add  x  to  S ; 

exist  X  in  S  suchthat  <  predicate> 

forall  X  in  5  suchthat  <  jn-edicato  do  <  statement> 

Sf't  orientation  helps  program  combinatorial  problems,  a  type  of  problems  common 
iu  \  LSI  C.4D.  It  provides  a  concise  notation  that,  since  it  is  part  of  our  common 
edueation.  helps  in  both  programming  and  documentation. 
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Data  abstractions  are  means  of  declaring  new  types.  The  following  few  lines  of 
code  is  an  example  of  such  a  declaration. 


cluster  list  (T) 

mode  T;  where  int  T;  /*  EC 

/•  This  list  implements  a  set  of  elements  of  typo  T  storing  copies  of 
elements  in  the  list  */ 


rep  type  listjst  *1; 

typodef  struct  {  type  listjt  enext; 

type  T  member; 

}  listjBt; 

fun  int  doit( ...)... {  ...  } 


/•  EC  3  •/ 


/*  EC  4  */ 


oper  void  opor  foralKelmont ,llist , st) 
type  T  olmont; 
type  list  Hist; 
statement  st; 

{ 

type  1  p; 

for(p=llist;  p*=(type  l)nil;  p=p->naxt) 
{  olmont  =  (p->member); 


proc  int  oper  add(elmont,lliet) 
type  T  elment;  type  list  Hist; 

{ 

type  1  p:  /♦  declaration  •/ 

for  (p  =  (type  1)  aiaHoc(eizeof(type  list-st}); 

p->meraber  =  elment; 

p->noxt  =  Hist; 

Hist  =p; 
result  1; 

I 


oper  typo  list  oper  ♦(...)  ...  {  ...  } 

constant  type  list  opor  nuH(clu8ter-name) 
craode  cluster-name; 

i 

(type  l)nil 

} 


/• 

EC 

7 

*/ 

/• 

EC 

8 

•/ 

/* 

EC 

9 

*/ 

/*  end  cluster  list  •/ 


A  tyjK'  is  by  ifs  rf'jirrsrntntion  (EC  3)  th*'  data  stnirturr  of  a  variable  u* 

tiiis  type;  and  !)y  a  set  of  operations.  Lint'  EC  4  flf'tines  the  operation  forall  wliO'C 
fall  is  as  follows: 


forall  element  in  Hist  do  stitteiiicnt 
[.ine  EC  C  defines  the  operation  add.  which  may  be  iiser!  in  the  following  manner: 


add  element  to  Hist 

Line  EC'  7  overloads  "+  t(.  be  the  nnion  of  two  s<'ts.  Line  EC  G  defines  a  constan:. 

null,  the  eini)ty  set. 

Tlu'  (duster  opertitions  ar<‘  s(d('cted  by  their  nanu'  and  the  types  of  tiudr  iuguinents 
(  polyinoiphic  ojx'rations ).  ('.g.  '  may  denot('  th<'  addition  of  intf'gers,  the  union  of 

sets.  ('tc.  Tlu'  compiler  s(defts  the  tijtpropriat e  operation  among  those  built-in  ;ind 
those  dciined  by  tin-  us(t. 

The  EC  clusters  tire  partinieterized.  E.g.  T  on  line  EC  1  is  a  type:  thi.s  cluster 
defines  a  set  of  T.  EC  cluster  operations  can  be  implemented  by  either  procedures  or 
macri’s.  The  former  cti.se  is  illustnited  on  line  EC  6  (key  word  proc)  and  the  later  is 
illusfrat('d  on  line  EC  5.  The  mticros  ptuform  substitutions  on  the  typed  synttix  tree. 

Mficro  implementations  of  cluster  operations  have  several  interesting  propertit's. 
They  avoid  the  itroceduri'  ctdl  overhead  and,  when  the  body  of  the  operation  is  small 
enough  they  itroduce  code  tlitit  may  be  both  faster  and  smtdler.  Since  binding  is 
done  at  compile  time  they  accept  both  statements  and  types  as  arguments  and  bind 
wirialilcs  "liy  name."  They  may  return  ■'lvalues'"  and  aj)pear  on  the  left  hand  side  of 
the  tissignment  statement. 

The  following  sections  di'scrilte  the  general  structure  of  tlu'  CAD  system  and  then 
dwidl  on  the  language  tispects  tlnit  tire  cenfr:d  to  our  discussion. 

•3.1  Sysfoiii  Orgailizafioii 

Figure  2  summarizes  the  system  organization  as  a  set  of  data  structures  with  the 
transformations  from  one  data  structur<’  to  another.  The  transfonmitions  .are  repre- 
si'iited  as  arrows. 

The  input  is  df'seribed  by  an  input  language.  The  comjxint'nts  are  described  by 
gi\ ing  ;i  (possil)ly  iiarameterizecl )  type  and  a  n;mie.  For  exam]^le. 


AND(WIRE(2))  al,  a2 ; 

de^i  iil.c-.  ,/|  and  e  .  as  two  com])onents  of  tyjie  AND(Wire(2) ) .  Wire(2)  is  a  type  and 
1-  ii-ed  a'  a  i)aramei,  i  of  type  AND.  component 's  connections  are  descrilted  l)y  stating 
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Input  Processor 


Figure  2.  CAD  tools  using  EC 


which  endpoints  are  connected  to  which  component’s  input  endpoint.  Although  this 
e.xarnple  does  not  show  it,  the  input  usually  describes  nested  networks,  i.e.,  components 
art’  defined  by  means  of  networks. 

Tlie  input  language  is  processed  by  a  program  that  we  call  the  input  processor 
\\’hon  that  program  encounters  a  type  it  searches  the  database  for  an  appropriate  type 
ilescription  described  below. 

The  database  is  arranged  as  Unix  files  and  directories.  A  directory  is  devoted  to 
each  type  (the  type's  directory).  Each  such  directory  contains  a  file  describing  the  com¬ 
ponent  topology,  i.e.  names  of  endpoints,  nature  of  endpoints  (input,  output,  tri-state). 
For  each  application  the  type  directory  contains  a  file  describing  the  component’s  prop¬ 
erties,  e.g.  power  and  size,  and  a  file  containing  the  cluster  describing  the  behavior  of 
th(’  type  for  each  application. 

The  input  processor  uses  the  topology  file  for  checking  for  input  consistency  and 
builds  a  general  network  data  structure  describing  the  network  (the  network  data  struc¬ 
ture  in  figure  2).  Each  element  is  described  by  an  object  (tuple)  whose  properties 
( coiii])onents)  are  the  basic  characteristics  of  the  elements  (name,  endpoints)  and  the 
application  properties  read  from  the  application  file. 

The  application  translator  is  a  program  that  runs  on  th(‘  general  data  structure  and 
l>roduces  the  application  program.  The  application  program  is  then  translated  by  the 
EC  compiler  into  runnable  code,  using  data  abstractions  called  from  the  database.  The 
oljject  code  is  run  on  the  input  to  produce  resuJt.s.  The  (new)  results  are  manipulated 
by  a  waveform  program  to  jiroduce  other  results  that  the  user  can  view,  print,  or 
otherwise  inspect. 

For  introducing  a  new  application  the  user  must  provide  the  database  entries  for 


■•  v^  i"»  »■•  i’^XTjr'jr^jr^jrr^'Vr’i 

'^i*' 


fli('  ;i Implication  aiul,  in  particular,  write  tlio  ap[mlication  traTi'^lator.  .All  other  facilities' 
are  provided  by  the  system. 

With  EC  as  the  main  tool  the  lanpuage  n.se<l  to  write  an  application  translator  is 
no  mystery;  it  is  EC  proper  plrrs  a  network  chtster  and  clusters  for  implementing  sets, 
secpiences  and  tuples.  Sincr>  the  input  ustially  rlefines  nt'sted  networks,  the  iietwoik 
clustc'r  contains  operations  that  produce  homologictd  copies  of  nested  networks.  For 
sets,  .serjuences.  etc.  the  programmer  itses  th<‘  langtiage  facilities  proviried  by  EC  and 
cliisteis  h(  either  extracts  from  the  stantlard  library  or  writes  himself.  The  network 
cluster  refjuires  somf'  additional  fdahortition. 

Otir  network  eh'iueuts  have  two  kinds  of  properties: 

•  ]iroimerties  that  are  tipplication  imhpoiulrnt  and  are  used  to  captuia'  the  natnie 
for  the  elements  as  part  of  a  network,  e.g.  connectivity.  We  call  these  jaoperties 
network  generic  properties 

•  Properties  that  are  application  dependent,  e.g.  the  device  function  in  the  siinula 
tion  application. 

A\e  would  like  to  generate  one  cluster  wljo.se  reprr'sentation  and  operations  inchult 
the  generic  operations  and  tin'  application  oriented  proimerties.  This  is  an  “inheiT 
tajicj'"  mechanism  the  new  cluster  inherits  the  properties  of  the  network  cluster  and 
a  (i)seudo)  cluster  whose  operations  are  the  applicati  >n  dependent  operations. 

•At  this  time.  EC  do<'s  not  have  automatic  inheritance  [4,  3,  14]  and  this  particular 
inla  ritance  is  done  in  the  way  described  below. 

(1)  The  input  proc<“ss<ir  generates  the  network  data  structure  as  a  fixed  part  per 
component  with  a  “hook"  for  application  dependent  properties.  Each  applicatiojj 
dep<  iKlent  entry  carries  its  name,  its  type  and  its  value. 

( 2 )  The  cluster  that  contains  the  generic  network  operation  is  augmented  by  operations 
that  access  the  application  properties.  These  operations  are  picked  up  from  the 
database  and  insert('d  (“include"  style)  into  the  network  clustju. 

4.  Use  of  Lisp  Machines  for  CAD 

SetIKMA  was  developed  using  Common  Lisp  on  a  Lisp  machine.  LiSP  is  extremely 
well  suited  for  building  new  languages.  Several  of  the  features  of  LiSP  contribute 
this  property.  Significant  power  is  achieved  through  the  use  of  data  abstraction  (as 
embodied  by  flavors  [4],  which  includes  inlu'ritance).  The  free  variables  of  procedures 
and  functions  can  be  closed  over  to  <T<'at<’  closun'.'i.  These  closures  are  first  class  citizens 
and  can  be  passfxl  t(m  and  from  othfT  functions  and  stored  in  data  structun's.  Finally, 
its  unifoj  ju  .syntax  (lack  of  it)  .simjtlifies  the  creation  of  semantic  ('xtf'iisions.  The  use 
of  macros  allows  these  extensions  to  be  incorporated  smoothly. 

At  least  two  integrated  \TSI  CAD  systems  have  been  built  on  Lisp  machines. 
Sc  ili'MA  [G]  is  being  developed  at  MIT  with  the  help  and  collaboration  of  colleagues  at 
Hairis.  Corp.,  and  XS  [5]  which  was  developed  at  Symbolics,  Inc.  These  two  systems 
shtiif'  a  common  heritage  from  the  Daedalus  system  de\x'loj)ed  at  MIT  [2]  and  many 
k<  y  idea". 
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Schema  was  developed  to  handle  all  of  the  aspects  of  designing  VLSI  circuits. 
Thus  it  contains  tools  for  schematic  entry,  layout  and  simulation.  Furthermore,  it 
is  built  upon  a  large  body  of  tools  that  can  be  used  to  build  additional  CAD  tools. 
Because  the  entire  design  and  all  of  the  tools  reside  in  a  single  address  space  a  somewhat 
different  approach  needs  to  be  taken  than  is  used  in  a  Unix  environment.  And  yet. 
there  are  still  strong  similarities  with  the  approach  used  in  EC.  The  following  diagram 
corresponds  to  figure  2  used  to  describe  the  EC  organization. 


.4s  with  EC,  the  core  of  the  design  system  is  the  network  description  language.  In 
Schema  this  language  is  interpreted  as  a  procedure  for  generating  a  memory  resident 
data  strvicture  that  describes  the  topology  of  a  circuit.  In  Figure  3  this  is  the  “Input 
Dc’scription.'’  This  language  may  make  use  of  definitions  of  other  circuits  from  a  library, 
rhus  allowing  the  hierarchical  description  of  circuit. 

The  data  structure  that  results  is  not  totally  passive.  Code  can  be  attached  to 
i-oiuponents  and  nodes  in  the  data  struct\ire.  (This  is  the  main  use  of  objected  oriented 
lirogramming  in  SCHEMA.)  Some  of  the  code  is  included  in  the  input  description  while 
iif'.H'r  code  is  added  by  application  programs.  Thus  a  simulator  might  add  code  to 
model  tlie  voltage  and  current  constraints  of  a  particular  device. 

Th('  hierarchical  network  data  structure  is  not  optimal  for  simulation  purposes. 
For  certain  types  of  simulations  it  contains  too  much  detail  (logical  simulators  are  not 
eoiiccnied  with  the  construction  of  an  AND  gate)  while  for  other  simulation  types 
tli<'  lii('rarchical  structure  gets  in  the  way.  To  deal  with  both  of  these  problems  a 
homological  copy  is  built  which  has  the  optimal  structure  for  the  application  program. 
Soil  km  A  ])rovides  mechanisms  for  building  and  operating  on  the  homological  cojries. 
which  are  extensions  of  the  network  description  language. 
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Tn  St'hfma  both  the  network  data  ‘Structure  and  its  homolojjfical  copies  reside  in 
iiK’uiory  simultaneously.  The  user  tends  to  deal  with  the  network  data  structure  and 
is  often  not  aware  of  the  homological  copy.  To  ease  the  use  of  the  system,  links  are 
preserved  between  the  homological  copy  and  the  network  data  structure.  This  allows 
fpiestions  about  the  result  of  simulations  to  be  directed  through  the  network  data 
structure  to  the  homological  copies. 

Perhaps  the  feature  of  tlie  Lisp  Machine  environment  that  distinguishes  it  the 
most  from  Unix-like  environments  is  that  all  the  design  tools,  as  well  as  the  design 
itself,  reside  in  a  common  address  space.  This  characteristic  makes  it  especially  easy 
for  disparate  CAD  tools  to  communicate  through  shared  data  structures.  For  instance, 
a  schematic  editor  and  a  simulator  are  abh'  to  examine  and  modify  a  common  data 
structure  that  reiwesents  a  topology  thus  simplifying  both  the  user  interface  to  the 
simulator  and  the  creation  of  incremental  analysis  tools.  Far  less  programmer  tinu' 
is  sjrent  flattening  data  structures  into  text  files  and  reparsing  them  for  use  in  differ¬ 
ent  tools.  The  “language"  in  which  the  CAD  tools  are  built  can  include  higher  level 
l)rimitives  than  text  files.  Furthermore,  the  co-residence  of  the  different  tools  allows 
one  CAD  tool  to  invoke  another  when  information  is  lacking.  Thus  a  circuit  simulator 
could  invoke  the  layout  program  to  inqtiire  about  the  capacitances  of  different  nodes. 
This  ai)proach  allows  the  tools  to  interact  as  collection  of  cooperating  experts  rather 
than  a  sequence  of  files  transducers. 

The  major  disadvantage  of  this  approach  is  that  modifications  and  annotations  to 
data  structures  persist  until  the  next  time  the  workstation  is  rebooted.  This  means 
that  modifications  to  data  structures  must  either  be  able  to  be  undone  when  necessary 
or  <ue  permanent. 


5.  Practice  and  Experience 


Two  iipplications  were  built  with  EC  using  this  philosophy.  The  first  is  a  simulator 
for  logic  networks  [7]  that  makes  extensive  use  of  the  network  layer  mentioned  earlier. 
The  second  system  does  automatic  layout  in  a  fashion  similar  to  PI  [17,  12].  The  same 
network  language  layer  was  used  to  create  nested  networks,  while  most  of  the  layout 
algorithms  were  built  on  another  layer  consisting  of  EC,  sets  and  sequences.  This 
>ystem  is  intended  as  a  testbed  for  a  variety  of  different  algorithms.  The  use  of  layered 
languages  made  the  expressions  of  the  algorithms  concise,  readable  and  easy  to  modify. 

The  network  langiuige  lay<'r  of  St’HE.MA  w;is  used  to  build  a  variety  of  diffe'rent 
simulators  and  as  an  interface  to  conventional  circuit  simulators  like  Spice  [11].  In 
fact  a  very  large  numljer  of  languages  layers  were  used  in  ScHl'.MA.  Among  them  w'ere 
layers  for  graplnc  imaging,  for  building  user  interfaces,  for  editing  graphical  structures, 
for  dealing  with  permanent  version  of  the  data  structures  in  SrilKM.A.  for  manipulating 
symbolic  mathematical  expressions,  etc.  In  each  case,  less  experienced  i)rogranimers 
were  able  to  construct  rather  sophisticated  api>lication.s  using  the  linguistic  tools  pro- 


6.  Summary  and  Conclusions 

The  two  systems  share  a  common  philosophy:  To  construct  a  CAD  tool,  first 
define  a  language  that  captures  the  concepts  common  to  the  field  and  widely  accepted 
by  workers  in  the  field.  Next,  build  the  CAD  tool  using  this  language.  For  example, 
consider  building  a  logic  simulator.  This  simulator  is  an  example  of  a  class  of  programs 
that  manipulate  networks.  We  begin  with  a  network  language,  and  then  extend  it 
to  one  that  is  appropriate  for  constructing  simulators.  The  logic  simulator  is  written 
in  the  simulation  language.  Notice  that  we  build  in  “extra”  generality.  The  network 
kinguage  can  be  used  for  problems  other  than  simulation.  The  simulation  language  can 
be  used  for  either  logic  simulation  or  circuit  simulation. 

This  philosophy  is  implemented  in  a  similar  fashion  in  both  systems.  In  both 
cas<\s,  the  system  is  built  on  a  base  language,  EC  and  LiSP  respectively,  with  addition 
problem  specific  languages  constructed  by  extending  the  base  languages.  In  EC  this 
is  done  using  clusters,  where  the  macro  oriented  operations  are  used  for  implementing 
control  abstractions.  In  LiSP  this  is  done  using  flavors  to  implement  data  abstraction: 
the  control  abstractions  are  implemented  using  macros  and  functional  arguments. 

The  differences  between  these  two  systems  revolve  around  two  points:  the  large 
address  space  used  by  LiSP  and  the  early  binding  by  compilation  used  by  EC.  The 
Lisp  machine  world  uses  a  very  large  address  space  allowing  many  tools  and  their  data 
structures  to  co-exist,  while  the  Unix/EC  world  places  each  tool  in  its  own  address 
space  and  shares  data  through  the  file  system.  The  Unix/EC  world  tends  to  bind  early 
have  the  compiler  make  as  many  decisions  as  possible,  while  the  Lisp  world  delays  those 
decisions  until  run  time. 

The  large  address  space  allows  SCHEMA  to  rely  on  “in  core”  data  structures  rather 
than  using  files.  This  allows  CAD  tools  to  share  common  data  structures  and  to 
communicate  simply  by  passing  pointers  to  these  data  structures.  This  environment 
allows  the  tools  to  appear  as  an  single  program.  This  eliminates  the  need  to  translate  to 
and  from  characters  to  the  data  structures  used  by  the  CAD  tools.  Furthermore,  CAD 
tools  are  now  able  to  invoke  other  CAD  tools  more  easily  in  this  common  environment. 

The  Schema  tools  include  the  schematic  entry  system,  the  layout  editor,  simulator 
and  others.  These  tools  share  common  network  data  structures,  but  often  have  slightly 
different  structures  for  their  own  use.  These  tools  and  their  data  .structures  all  co-exist 
in  the  same  large  address  space. 

The  early  binding  by  compilation  used  by  EC  has  advantages  and  disadvantages. 
Ihe  disadvantages  are  that  the  communication  between  the  results  and  the  original 
>pe(  iHcation  of  the  network  has  to  be  done  via  files  and  dictionaries,  which  complicates 
the  C.4D  system.  And  if  the  application  requires  iteration  across  the  boundaries  be¬ 
tween  CAD  tools  that  application  becomes  quite  expensive.  The  advantage  of  early 
binding  by  compilation  is  the  gain  in  run-time  performance  for  CPU  bounded  problems. 

The  comparison  between  run-time  performance  of  conventional  machines  running 
(■oini)iled  EC  and  the  Lisp  machine  running  Lisp  is  not  simple.  We  do  not  have  signifi- 
•anf  rest.'  that  run  in  both  environments.  The  Lisp  system  attains  speed  improvements 
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liv  ^i'p<‘i;tl  hardware  and  by  rompilaticm.  We  don't  feel  that  there  is  any  reason  why 
this  method  is  should  be  inherently  slower  or  faster  than  a  conventional  environment. 

Currently  a  LiSP  machine  system 's  a  relatively  expensive  item.  The  Unix  system 
nms  on  conventional  machines. 
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